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INTRODUCTION 

The  cloud  analytics  and  collaboration  environment  (CAGE)  is  an  existing  thin  client 
collaboration  solution  that  enables  collaboration  between  Intelligence  (G2/S2)  and  Operations 
(G3/S3)  communities.  It  is  a  dashboard-style  web  application  designed  to  securely  host  widgets  and 
provide  a  framework  for  real-time  collaboration  between  clients,  allowing  for  a  plug  and  play  type 
architecture.  Upon  an  initial  review  of  this  application,  it  appeared  to  support  the  core  capabilities 
envisioned  by  the  command  post  computing  environment  community  for  Tactical  Applications 
[TacApps  (ref.  1)].  However,  as  a  complete  government  off-the-shelf  (GOTS)  solution,  CAGE  is 
missing  two  key  pieces:  disconnected  operations  and  a  decentralized  server.  Despite  these 
drawbacks,  GAGE  still  possesses  a  number  of  features  that  are  likely  to  be  reusable  in  TacApps. 

The  reuse  of  these  components  would  benefit  the  government  by  leveraging  GOTS  software  to  fulfill 
several  collaboration  requirements. 


CLOUD  ANALYTICS  AND  COLLABORATION  ENVIRONMENT  BACKGROUND 

The  CAGE  was  initially  funded  by  the  U.S.  Army  Intelligence  Information  Warfare  Directorate, 
as  well  as  other  U.S.  Army  initiatives  over  the  last  6  yr.  Some  of  the  large  initiatives  in  which  CAGE 
was  leveraged  include  the  collaboration  and  battlespace  reasoning  and  awareness  Army  technology 
objective  (COBRA  ATO),  actionable  intelligence  -  technology  enabled  capability  demonstration  (Al- 
TECD),  advanced  video  activity  analytics  (AVAA),  and  the  cloud  analytics  for  warfighter  situational 
awareness  (CLAWS).  The  CAGE  fully  implements  the  ozone  widget  framework  (OWE)  JavaScript 
application  programming  interface  (API),  allowing  OWF  widgets  to  function  within  CAGE  without  any 
modifications  to  their  code.  In  addition  to  leveraging  investments  made  in  the  OWF  API,  CAGE  offers 
its  own  open  collaboration  API  that  allows  any  widget  to  take  advantage  of  its  real-time  collaboration 
via  WebSocket  communication.  The  CAGE  also  offers  APIs  for  alerting  and  file  sharing  and  provides 
dynamic  workflows,  cross-widget  eventing,  and  map  frameworks.  Critical  security  enhancements 
were  built  into  the  dashboard,  removing  many  of  the  security  flaws  present  in  previous  OWF 
versions.  The  security  enhancements  also  exist  at  the  data  transport  layer  and  server  (ref.  2). 


CLOUD  ANALYTICS  AND  COLLABORATION  ENVIRONMENT  ARCHITECTURE 

The  CAGE  offers  a  pluggable  architecture  in  which  non-core  services  can  be  turned  on  and 
off  via  an  administrative  service  panel.  Non-core  modules  can  also  be  enabled  on  a  per  user  basis 
As  part  of  core  functionality,  CAGE  provides  eventing,  a  message  center,  chat,  search,  document 
upload  and  tagging  capability,  map  data  management,  and  topic  forums  to  facilitate  collaboration. 
The  CAGE  contains  three  main  types  of  communication:  inter-widget,  between  CAGE  users,  and 
cross-system  data  sharing.  Communication/collaboration  mechanisms  include: 

•  Custom  WebSocket  implementation 

•  Representational  state  transfer 

•  Java  messaging  service 

•  Java  application  programming  interface  (API) 

•  Internet  relay  chat  (IRC)/extensible  messaging  and  presence  protocol  (XMPP) 

•  Cursor  on  target 

•  Data  dissemination  service 
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Figure  1  details  the  overall  CAGE  architecture  represented  by  a  single  CAGE  server,  which 
hosts  the  GAGE  application  on  either  a  JBoss  application  server  or  an  Apache  Tomcat  servlet 
container  instance.  The  relational  database  management  system  can  be  either  PostgreSQL  or 
MySQL.  The  GAGE  clients  are  standard  web  browser  clients.  A  client  is  counted  as  a  single 
browser  instance  (process)  with  one  tab  (browser  window).  The  communication  between  the  GAGE 
clients  can  occur  if  they  are  on  the  same  node  as  the  GAGE  server  or  a  different  node.  As  shown  in 
figures  1 , 2,  and  3,  the  architecture  GAGE  has  the  ability  to  host  OWF  widgets  within  the  workspace 
and  have  it  appear  as  a  local  widget  to  the  end  user.  Single  sign-on  is  handled  within  the  GAGE 
application,  removing  the  burden  from  an  end  user  to  provide  login  information  to  each  external 
widget  or  chat  service  (IRG  or  XMPP). 


*Not  a  distributed  architecture  -  local  CAGE  enclaves  do  not  interoperate 


Figure  1 

GAGE  architecture 


Figure  2 

GAGE  web  application  components 
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collaborated  in  real-time  with  other 
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CAGE  Web  Application  (Collaboration  Service) 


Figure  3 

CAGE  collaboration  detail  (ref.  2) 

The  CAGE  widgets  implement  the  OWF  API  and,  as  such,  have  the  ability  to  respond  to 
OWF  events.  The  OWF  widget  events  are  also  propagated  to  multiple  GAGE  users  via  a  client-side 
publish  and  subscribe  mechanism  where  events  are  relayed  via  JavaScript  object  notation  objects 
over  WebSockets.  The  GAGE’s  chat  component  also  solely  makes  use  of  collaboration  over 
WebSockets  for  internal  chats.  Messages  received  by  external  chat  services  are  processed  by  a 
GAGE  internal  service  that  mimics  the  behavior  of  a  typical  chat  client  of  the  external  service. 
Messages  are  then  relayed  to  the  intended  GAGE  user  over  WebSockets.  In  the  reverse  scenario, 
messages  sent  from  a  CAGE  client  to  an  external  chat  source  are  sent  over  WebSockets.  Once 
received  by  the  CAGE  server,  these  messages  are  then  translated  to  the  messaging  format 
supported  by  the  external  service  and  published  for  the  external  recipient  who  may  or  may  not  be  a 
CAGE  user.  This  illustrates  the  versatility  of  CAGE’S  collaboration  beyond  registered  CAGE  users. 
The  server-side  instance  of  the  CAGE  application  is  responsible  for  the  construction  of  a 
WebSocket,  deconstruction  of  a  WebSocket,  and  maintenance  of  internal  mappings  of  open  client- 
to-WebSocket  connections.  These  connections  are  used  as  the  backbone  of  client-server 
communication  for  relaying  events  and  chat  messaging  to  and  from  client(s). 
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SERVICES  AND  COMPONENTS  OF  INTEREST 

The  TacApps  has  a  need  to  provide  a  notification/eventing  mechanism  between  its 
components  (ref.  3).  Requirements  also  call  out  for  a  chat  component  that  provides  both  group 
messages  (broadcast  capability)  and  private  messages  among  individual  TacApps  users  (ref.  3). 
Services  and  components  of  interest  that  are  candidates  for  reuse  in  TacApps  to  fulfill  these 
requirements  are: 


•  Notification  (eventing) 

•  Messaging  (includes  chat) 

•  External  chat  service(s)  compatibility 

•  OWF  inter-widget  communication 


LEVERAGING  CLOUD  ANALYTICS  AND  COLLABORATION  ENVIRONMENT  FOR  TACTICAL 

APPLICATIONS 

Reuse  of  CACE  components  in  TacApps  will  not  be  a  simple  plug  and  play  action  as  the  core 
functionality  provided  in  CAGE  is  tightly  coupled.  However,  reusing  CAGE  components  is  not  an 
impossible  task,  and  leveraging  these  pieces  will  likely  result  in  both  schedule  and  cost-saving 
benefits. 

Chat  Component 

These  CACE  object  classes  and  related  JavaScript  classes  are  candidates  for  TacApps 

reuse. 


•  com. impulse. messaging. ChatWebSocket  -  WebSocket  class  that  can  process 
chat  messages  received  by  the  client,  presence  updates,  and  disconnects. 

•  com. impulse. ire. IRCService  -  registers  as  a  client  for  the  authenticated  user  and  is 
able  to  publish  and  receive  messages  to  the  external  IRC  service. 

•  com. impulse. messaging. model. ChatMessage  -  model  of  a  chat  message. 

•  com.impulse.xmpp.XMPPService  -  registers  as  a  client  for  the  authenticated  user 
and  is  able  to  publish  and  receive  messages  to  the  external  XMPP  service. 
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Inter-widget  Messaging  Component 

•  User  interface  (ui)/scripts/iframe/iframebridgeclient.js  -  supports  external  widgets  that  are 
hosted  within  an  Iframe.  Messages  or  events  from  those  widgets  are  posted  via  this  class 
which  then  coordinates  with  the  browser’s  cross-window  messaging  “postMessage” 
functionality  to  communicate  with  the  internals  of  CAGE. 

•  ui/scripts/iframe/iframebridge.js  -  supports  external  widgets  that  are  hosted  within  an 
Iframe  by  receiving  messages  or  events  that  are  posted  to  the  browser’s  cross-window 
messaging  “postMessage”  functionality  by  iframebridgeclient.js.  The  iframebridge.js  can 
be  seen  as  the  gateway  into  the  communication  of  internals  of  CAGE  by  outside  widgets. 

•  ui/core/externalmanagers/externalsystemeventdispatcher.js  -  client  side  publish  and 
subscribe  wrapper  for  the  internal  systemeventdispatcher.js,  typically  invoked  by  widgets 
that  directly  implement  the  CAGE  API  and  also  by  OWE  widgets  that  are  virtually  hosted 
by  CAGE. 

•  ui/core/externalmanagers/externaldragdropmanager.js  -  handles  drag  drop  operation 
between  widgets. 

Messaging  Component 

These  CAGE  object  classes  and  related  JavaScript  classes  are  candidates  for  reuse  in 
TacApps. 


•  com. impulse. eventing. SystemEventDispatcher  -  responsible  for  transaction 
synchronization  and  coordination  of  message  dispatching.  Accepts  system  event 
messages  that  are  of  type  serializable  and  sends  them  to  MessagingServlet. 

•  com. impulse. messaging.AbstractWebSocket  -  base  WebSocket  class  that  is 
aware  of  how  to  broadcast  messages  and  disconnect  clients. 

•  com. impulse. messaging. InboundWebSocket  -  general  WebSocket  class  that 
handles  ALL  events  and/or  messages  not  of  type  serializable  that  are  received 
from  the  client. 

•  com. impulse. messaging. MessagingServlet  -  maintains  a  running  list  of  open 
WebSockets  with  corresponding  user  for  message  distribution.  Receives  system 
events  (including  chat  messages)  and  publishes  them  to  the  client. 

•  ui/core/managers/systemeventdispatcher.js  -  client  side  publish  and  subscribe 
component.  Handles  and  maintains  listeners  that  require  a  callback  when  system 
events  occur. 

•  ui/scripts/jjms.js  -  client  side  WebSocket  component  responsible  for  initiating 
construction  and  de-construction  of  WebSockets.  Also  handles  default 
processing  on  receipt  of  messages  sent  via  WebSocket. 

Ozone  Widget  Framework 

These  CAGE  JavaScript  classes  are  candidates  for  reuse  in  TacApps. 
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•  ui/core/framework/owfsupport.js  -  handles  all  OWF  widget  events  and 
communication. 

It  is  important  to  note  that  the  OWF  functionality  makes  use  of  and  is  dependent  upon  the 
inter-widget  messaging  component  mentioned  previously  (fig.  4). 


Figure  4 

TacApps  messaging  component  class  diagram  (ref.  4) 


TACTICAL  APPLICATIONS  COMPONENT  INTEGRATION 
Tactical  Applications  Messaging  Component 

The  core  of  CAGE  message  delivery  system  is  supplemented  by  additional  classes  for 
TacApps  specific  functionality.  Supplemental  classes  of  interest  are: 

•  MessagingCenterService  -  service  that  provides  message  and  alert  management 
functionality  to  the  TacApps  Ui  component. 

•  MessagePriorityEnum  -  assists  in  prioritizing  messages  for  Ui  management. 

•  AlertMessage  -  user-defined  message  of  interest  upon  which  delivery  is  triggered 
on  situational  changes/updates. 

•  EventTypeEnum  -  used  to  differentiate  messages  for  delivery.  Recipients  may  opt 
on  receipt  of  specific  messages  only  and  tailor  consequential  actions 
appropriately. 

Tactical  Applications  Chat  Service  Component 

The  class  diagrams  for  TacApps  ChatCoordinatorService,  internal  and  external  chat 
managers  are  shown  in  figures  5  through  7. 
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pkg  ChatCoordinatorSeivice  Class  Diagram J 


ChatCoordinatorService 


+  persistChatMessageO:void 
+  sendChatMessageO:void 
+  closeChatO:void 
+  clearChatHistoryO;void 
+  geWIIChatsO:void 
+  getUserPresenceO:void 
+  notilVUserConnectO:void 
+  setChatServicesO:void 
+  updateUserPresenceO:void 
+  notif/UserPresenceO:void 


MessagiiigServlet 


+  setUserStatusO:void 
+  dispatchEventO:void 
+  initO:void 

t  createWebSocketInboundO :  void 
+  getUserStatusO:void 
+  getlnstanceO:void 
'^sessionExpiredQivoid 


Bridge  to  the  client  over 
web  sockets 


Pushing  chat  ^ 

notifications  to  and  from 
the  browser 


Figure  5 

TacApps  ChatCoordinatorService  class  diagram  (ref.  4) 


Internal  Chat  Manager  Class  Diagram  J 


ChatCoordinatorService 


*  persistChatMessageO  :voicl 

*  sendChatMessageO :  void 
+  eloseChatO  :vold 

*  clearChatHistotyO :  void 

*  gelAiiChatsO  :void 

*  getUserPresenceO :  void 
+  notifyUserConnectO :  void 

*  setChatSeivicesO  :void 

*  updateUserPresenceQ :  void 

*  notifyUserPresenceO :  void 


«uses» 


ReceiverAdapler 


*  receiveo :  void 
*viewAcceptedO  :void 


Maintain  a  iist  of 
channels  for  each 
person  we  chat  with, 
channel  is  destroyed 
when  chat  is  closed 


*  getChatCoordinatorServiceO :  void 
+  sendChatMessageO  :void 


JChannel 


» connecto :  void 
»closeO:vald 

*  sendO :  void 

*  disconnectO ;  void 

*  getViewO :  void 

*  InitO :  void 


ChatMessage 


getSourceO  :void 
getMessageO :  void 
*•  gefTImeStampO  :void 
getDestInationO  :void 
^  isPrivateMessageO  -  void 
getIdO  :void 


!<receives/s»nds^ 


|groups.Message 


♦  getDestO  :void 

♦  getSrcO  :void 

+  getHeadersO :  void 

♦  gelRawBufferO  ;void 


+  getMembersO :  void 
+  sizeO :  void 


Setter  methods  are  ^ 
assumed,  leaving  them 
outfor  simplicity 


Using  JGroups  here.  One  ' 
main  clusterforTacApps 
communication.  Group 
messages  can  be  sent  via  sub 
clusters 


Figure  6 

TacApps  internal  chat  manager  class  diagram  (ref.  4) 
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pkg  External  Chat  Manager  Class  Diagram^ 


Figure  7 

TacApps  external  chat  manager  class  diagram  (ref.  4) 

The  TacApps  chat  component  borrows  external  chat  service  integration  from  CAGE; 
however,  the  chat  component  updates  the  internal  chat  mechanism  (TacApps-to-TacApps)  to  work 
synergistically  with  the  TacApps  architecture.  This  design  is  necessary  because  it  is  not  feasible  to 
depend  on  WebSockets  for  client  to  server  communication  across  nodes  that  already  host  a  client- 
to-server  local  solution  (as  needed  for  disconnected  operations).  The  standout  classes  are: 

•  ChatService  -  interface  of  which  all  external  chat  services  must  comply  at 
minimum.  TacApps  will  reuse  CAGE’S  XMPPService  and  IRCService  as 
implementers  of  the  ChatService.  The  ChatService  closely  resembles  CACE’s 
ChatSink  class;  however,  additional  messages  are  part  of  this  new  interface  that 
is  pertinent  to  TacApps.  Updates  are  planned  to  be  made  to  the  implementing 
classes  to  comply. 

•  ChatCoordinatorService  -  coordinates  messages  between  Ul  and  TacApps-to- 
TacApps  as  well  as  coordinating  messages  between  Ul  and  TacApps-to-External 
Chat  Service. 

•  TacAppsChat  -  facilitates  instant  messaging  between  TacApps-to-TacApps  by 
using  a  brokerless  service  as  the  messaging  backbone  to  promote  auto  discovery 
among  TacApps  nodes. 
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ISSUES  AND  RISKS 


Three  of  the  identified  risks  are: 

•  Risk  1  -  JavaScript  calls  to  the  server  for  service  functionality  within  CAGE  are 
currently  done  through  a  Java  library  called  direct  web  remoting.  This  library  has 
been  part  of  the  core  CAGE  architecture  for  quite  some  time;  however,  there  have 
not  been  new  developments  in  this  library  since  September  201 4.  The  most  recent 
version  of  the  library  is  version  3.0.0-rc3;  however,  this  version  is  not  compatible 
with  GAGE  as  obtained  directly  from  http://directwebremoting.org/dwr/index.html. 

•  Risk  2  -  Analysis  was  performed  on  Apache  Tomcat  7;  as  of  April  2015,  GAGE 
officially  supports  Apache  Tomcat  7  and  JBoss  7.  The  GAGE  has  not  been 
officially  tested  with  WildFly  (official  name  for  JBoss  8)  nor  Apache  Tomcat  8.  The 
GAGE  makes  updates  to  the  deployment  of  Apache  Tomcat  7  and  JBoss  7; 
however,  TacApps  team  developers  were  informed  by  GAGE  developers  that 
these  server  updates  in  support  of  WebSockets  would  not  be  necessary  in  the 
future  server  versions. 

•  Risk  3  -  Although  OWF  widgets  can  be  virtually  hosted  within  GAGE,  the  reverse 
is  not  true;  GAGE  widgets  cannot  be  hosted  by  an  OWF  server  as  the  unique 
collaboration  of  widgets  across  multiple  clients  will  be  lost.  This  is  important  to 
note  with  TacApps  since  one  of  TacApps  goals  is  to  interoperate  with  OWF.  It  is 
worth  considering  whether  or  not  GACE’s  approach  regarding  a  unidirectional 
OWF  compatibility  is  what  is  needed  in  TacApps.  By  traversing  a  bi-directional 
path  of  OWF  compatibility,  TacApps  widgets  may  lose  inter-widget  communication 
across  multiple  clients  (which  is  the  desired  behavior).  Further  investigation  is 
needed  for  the  latter  approach  when  hosted  on  an  OWF  server. 


CONCLUSIONS 

The  Tactical  Applications  (TacApps)  Program  is  likely  to  benefit  from  reusing  the  core 
components  and  services  of  cloud  analytics  and  collaboration  environment  (CAGE)  related  to 
collaboration  of: 

•  Notification  (eventing). 

•  Messaging  (includes  chat). 

•  External  chat  service(s)  compatibility. 

•  OWF  inter-widget  communication. 
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Although  the  architecture  for  TacApps  differs  from  CAGE  in  that  TacApps  data  is  distributed, 
it  uses  a  non-centralized  server,  and  has  the  capability  of  operating  under  disconnected  intermittent 
low-bandwidth  conditions;  the  communication  requirements  between  the  client-to-server(s)  and 
client-to-client  remain  the  same.  By  reusing  the  aforementioned  components  and  services,  the 
TacApps  Program  will  be  leveraging  technology  that  has  been  proven  in  a  program  for  the  U.S. 
Army.  This  is  not  to  imply  that  it  would  be  a  simple  plug  and  play  solution  as  the  CAGE  functionality 
is  tightly  coupled  within  the  architecture.  However,  by  using  the  key  classes  and  applying  design 
modifications  as  outlined  in  this  report  (and  further  detailed  in  the  tactical  applications  software 
design  document)  to  comply  with  TacApps  requirements  and  architecture,  the  benefits  of  this  reuse 
are  clear. 
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